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Abstract 

A suite of telerobotic tasks has been compiled and assessed for the 
purpose of selecting viable tasks for near and far term laboratory demonstra- 
tions. The primary intent of developing the task suite is to provide some 
technical guidelines, with supporting data, for focusing NASA laboratory 
demonstrations toward application domains that address a wide array of 
potential telerobot tasks and required technologies. This wide application 
would then result in a rich technology development environment to meet the 
broad task requirements of a system such as the Flight Telerobot Servicer (FTS) . 

This paper describes the methodology and results of the telerobot task 
assessment, including a ranking of the final select suite of major tasks. The 
study approach, database, and results of the task ranking computation are 
presented along with guidelines for both interpreting the task ranking results 
and setting programmatic objectives based on these results. The report also 
provides detailed data about the task candidates and their respective levels of 
complexity, task primitive actions, and the actual relative measures of task 
worth as associated with key tradeoff variables such as cost, available research 
resources, technology availability, and importance to the user community. 

Introduction 

The primary purpose of this task study was to compile a list of tasks that 
represented viable candidates for laboratory demonstrations, and satisfied two 
major constraints: 

1. The tasks must clearly demonstrate application to a real-world user problem 
in the space environment, such as Space Station assembly or servicing. 

2. Selection of the suite of tasks must reflect existing resource constraints 
within NASA telerobot research community. 

In the process of structuring the task assessment and developing the suite of 
demonstration tasks, it became clear that the assessment contained additional 
information that could be useful to the telerobot research community: 

1. The assessment, through its structure, provides a means of rationalizing 
the task selection process. 

2. The assessment provides a traceable means for reasoning why one task tends 
to represent a better demonstration target than another. 

3. The assessment, through its methodology and supporting task-related data 
(e.g., cost, technology contribution, resource availability, and user 
importance) , provides a blueprint for mapping out near-term and long-range 
technology development and demonstration objectives as a function of 
varying task-complexity levels. 

Approach 


In order to develop the prioritized suite of tasks, we first wrote a. straw- 
man report that included a preliminary list of tasks extracted from NASA 
documents, description of the multi-attribute decision-analysis method for 
ranking these tasks, tentative data (attribute weights and utility values) for 
computing the ranking, and preliminary task-ranking results. This report was 
distributed to several telerobot NASA Centers and contractors for review. We 
then visited the following NASA Centers and contractors: 

NASA Goddard Space Flight Center 
NASA Langley Research Center 

General Electric RCA, Advanced Technology Laboratories 

Massachusetts Institute of Technology (MIT), Aerospace Engineering Dept. 

NASA Marshall Space Flight Center 

NASA Johnson Space Center 

Jet Propulsion Laboratory 

NASA Ames Research Center 

At each Center the straw-man report was presented, the findings were 
discussed and feedback was received from the Center's professional staff. The 
feedback from all of the Centers was used to adjust the results to reflect 
their respective resident experience. 
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One of the first steps in performing the task assessment was to compile a 
straw-man list of potential tasks. It was understood at the outset of this 
study that the deadline for completion of the assessment constrained the scope 
of the study. It was therefore decided to first develop broad potential 
categories of tasks, and then list tasks within each category. The major task 
categories, derived from existing NASA documents, were as follows: 

1. Assembly — The process of physically connecting mechanical or electrical 
components . 

2. Servicing - Various processes involving the removal and replacement, 
adjustment, refurbishment, or reconfiguration of spacecraft components. 

3. Inspection - The process of using telerobotic sensing to determine the 
integrity of a spacecraft component. 

4. Material Handling - The process of actively transporting and replacing 
supplies for performing assembly or servicing functions (e.g., pick-and- 
place supplies from the shuttle to an assembly site). 

5. Manufacturing - The process of converting raw materials into finished 
products in the Space Station. 

Tasks were selected drawing largely from documents describing the Robotic 
Assessment Test Sets (RATS) [1] and the Polar Platform Payload Servicing require- 
ments [2], We also examined Space-Station tasks and manifesting studies 
performed by the various work-package subcontractors [3,4,5], One question 
that arose was the degree to which the suite of straw-man tasks comprehensively 
represented the total array of near-term tasks related to the Space Station. 

We examined two larger, more comprehensive task studies, the MIT ARAMIS and 
McDonnell Douglas THURIS studies [6,7], and compared them against our categories 
and the straw-man list. We found that, although they are more comprehensive in 
defining different tasks elements, both the ARAMIS and THURIS task listings 
could be represented as components of the straw-man suite of tasks we selected 
as demonstration candidates. Task comprehensiveness was also affected by 
inputs from the different NASA Centers we visited. During each session in which 
we discussed the straw-man task-ranking analysis with the respective Center's 
staff, we collected additional potential tasks. These tasks were then examined 
to determine whether they were different from the list already compiled, or 
whether they could be considered a subset of another task already on the list. 

Table 1 lists 23 tasks considered unique from the standpoint of representing 
different size and scale of objects, different types of manipulation, and 
different kinds of technologies. Among the 23 tasks in Table 1, only the first 
18 tasks were ranked because the details of the remaining ones were insufficient. 
Having selected this set of candidate tasks, the next step was to rank them in 
the order of their utility ("worth" or suitability) as domains for demonstra- 
tion of telerobotic techniques. These techniques may be applicable to future 
NASA missions, in particular to those associated with the Space Station. A 
variety of factors were listed, called attributes, that have a direct effect on 
the task ranking. We then used the Multi-Attribute Decision Analysis (MADA)[8] 
method to rank the candidate tasks on the basis of the effect of each attribute 
on the suitability of each task as a domain for telerobotics R&D. MADA provides 
a decision structure with which to rank several task options based on an 
aggregate value of the net worth measured across several attributes. The follow- 
ing discussion defines the MADA technique and explains how it was applied to the 
task ranking. 

Capabilities of Multi-Attribute Decision Ana lysis (MADA) 

Task ranking based on a set of different attributes may pose some problems. 
The original guidelines under which the task assessment was initiated indicated 
that we had to compile a suite of tasks that was appealing to the user 
community and that could be developed and demonstrated in the laboratory within 
limited resources. These guidelines may lead to conflicting results, because 
tasks that possess attributes important to NASA's user community may require 
more laboratory and professional resources than the NASA Centers have. Further, 
some attributes, such as "Importance to User" or "Technological Contributions," 
are more easily measured qualitatively than quantitatively. 

Multi-attribute decision analysis facilitates decision-making in the 
presence of conflicting attributes, measured either qualitatively or quantita- 
tively. MADA is based on the premise that individuals knowledgeable in the area 
of interest (in this case, task demonstration designers) can express their 
preferences among different options if provided with an appropriate decision 
structure that enables them to make comparisons and quantify their responses. 
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The quantification of their responses is in the form of a so-called utility 
value - a metric that measures the net worth, or effectiveness, of a given 
option to the group of knowledgeable individuals. The quantification process 
draws on well-developed and tested methods of decision analysis [8,9,10]. 

Selection of Attributes 


To be able to apply MADA to the task ranking,. the following seven 
attributes were selected: 

•Cost - The approximate design, development, test, and evaluation (DDT&E) 
cost of the hardware and software required to demonstrate a task. 

•Technology Demonstration/Development Schedule - The time required to 
acquire and/or develop the technologies, hardware, and software required 
for a task, design and integrate the system, and demonstrate the task to 
a specified level of robustness. 

•Importance to User - The degree to which a task can be applied to real 
world problems, meets the requirements of the user community, utilizes a 
domain the user community feels is important, and, if done successfully, 
enables completion of other similar tasks. 

•Productivity/Safety Impact - The potential for a telerobotic task to 
increase the productivity of an astronaut and reduce his/her adverse risk. 
Aspects of productivity include reduction in EVA time and the amount of 
time an astronaut or ground crew is freed to do other tasks. Safety is 
primarily related to reduction in hazard exposure, whose two main factors 
are the hazard severity and exposure time. 

•Center Resources - The degree to which the hardware and software and the 
technical personnel required by a task are available in any of the various 
NASA Centers . 

•Technological Contributions - Contributions to advancing the state of the 
art of the technology elements required to perform a task. 

•Possible Near-Term Demonstration Success - The estimated confidence that 
a laboratory demonstration of a given task will succeed. 


TABLE 1: List of Candidate Telerobotic Tasks 

ASSEMBLY TASKS 

1. Truss Assembly 

2. Utility Tray Deployment and Pop-Up Connector Utility Line Installation 

3. Station Interface Adapter (SIA) to Truss Connection 

4. Payload Interface Adapter (PIA) to Station Interface Adapter (SIA) Connection 

5. Solar Dynamic Array (SDA) Radiator Assembly and Deployment 

SERVICING TASKS 

6. Solar Power Converter Orbital Replacement Unit (ORU) Changeout 

7. High Resolution Solar Observatory (HRSO) Film Canister Changeout 

8. Hubble Space Telescope (HST) Axial Instrument Changeout 

9. Hubble Space Telescope (HST) Reaction Wheel Assembly (RWA) Changeout 

10. Gamma Ray Observatory (GRO) Refueling 

11. Earth Observatory System (EOS) Instrument/Orbital Replacement Unit (ORU) 

Changeout 

12. Solar Maximum Mission (SMM) Main Electronics Box (MEB) Replacement 

13. Earth Observatory System (EOS) Instrument Reconfiguration 

14. Earth Observatory System (EOS) Instrument Recalibration/Adjustment 

15. Extra Vehicular Activity (EVA) Retriever 

16. Telerobotic Docking 

INSPECTION TASKS 

17. Electrical Connector Removal/lnspection 

18. Clean/Inspect Surface (Solar Cell Cleaning) 

TASKS CONSIDERED UNIQUE BUT NOT RANKED BECAUSE OF INSUFFICIENT INFORMATION 

19. Position/Push RCS Thruster 

20. Alpha Joint Position/lnstallation 

21. Antenna Position/lnstallation 

22. Repair Manipulator Arm on Platform 

23. Specific Failure Recovery Schemes 
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The importance of each of the above seven attributes relative to each other 
depends on the main drivers behind the development of telerobotic techniques and 
task demonstrations. We represent the relative importance of each attribute 
by an attribute weighting factor, called attribute weight, whose value varies 
between 0 and 1. During our visits to the various Centers we were urged to 
consider two different sets of attributes, user attributes and research 
attributes. As a result, we established the two attribute lists shown in 
Table 2. 

TABLE 2: Attributes Important to User and Research Communities 

User Attributes Research Attributes 

a. Cost 

b. Technology/Demo Development Schedule 

c. Importance to User 

d. Productivity/Safety Impact 


Our visits made clear the need for a new attribute called "Demo Fidelity" 
or "Demo Realism." Changes in dynamics due to scale, inertial characteristics, 
lighting, or weightlessness definitely alter the usefulness of the results. This 
attribute was incorporated into the attribute "Importance to User. Therefore, 
the more closely a laboratory demonstration approaches the real on-orbit task, 
the higher its utility to the user. 

The agreed-upon approach for handling the two sets of attributes was 
realized by applying different weights to the attributes, depending on whether 
the task ranking was being done for the user community or the research community. 
Those tasks that ranked equally high for both communities would then make up the 
desired task suite. The other major distinguishing factor for segregating the 
desired task suite from the rest of the tasks was whether the tasks that had 
high ranking in the research community had application to the high-ranking (but 
different) tasks in the user community. This would mean that, indeed, the 
final suite of tasks had importance to the user community as a whole. 


a. Cost 

b. Technology Demo Development Schedule 

c. Importance to User 

d. Center Resources 

e. Technological Contribution 

f. Possible Near-Term Demo Success 


Utility Values 

Using MADA, once the attributes and their relative importance weights are 
established, the next step is to develop measures by which to determine the 
utility (the net worth) of a given candidate task in relation to each attribute. 
The measure of worth of a given task candidate is the utility value of that 
particular task. For example, the cost attribute, measured in 1988 dollars, 
reflects the rough cost of constructing the required hardware/sof tware testbed 
in the laboratory to perform a given task. Tasks that could be done within the 
budget constraint have high utility values for that attribute; conversely, 
tasks that exceeded the budget constraint have low utility values. Similarly, 
different utility values correspond to each task for each of the other attributes. 
The measures used to estimate each of these utility values are described in 
Reference [11]. It is important to recognize that derivation of actual utility 
measures, using empirical data, provides the most accurate ranking outcome. The 
data presented in Reference [11] reflects an attempt to use as much empirical 
data as possible. 

Classically, MADA requires that utility values range between 0 and 1. To 
facilitate the assignment of utility values, we classified the utility of each 
attribute relative to any task into three levels: Low utility (0.0 to 0.3), 

medium utility (0.3 to 0.6), and high utility (0.6 to 1.0). These ranges are 
shown in Table 3. 


TABLE 3: Utility Value Ranges 

Attributes 

Cost 

Technology /Demo Development Sch. 
Importance to User 
Productivity/Safety Impact 
Center Resources 
Technological Contributions 
Possible Near-Term Demo Success 


Low Utility Medium Utility 
(0. 0-0.3) (0.3-0. 6) 


High Cost 

Far Term 

Low 

Low 

Absent 

Low 

Low 


Medium Cost 

Medium Term 

Medium 

Medium 

In Process 

Medium 

Medium 


High Utility 
( 0 . 6 - 1 . 0 ) 

Low Cost 
Near Term 
High 
High 

Exist ing 

High 

High 
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Detailed utility values were calculated by using the measures defined above. 
Applying the ranges indicated in Table 3 allowed Center participants to under- 
stand what was meant by a task having low, medium, or high utility value. 

During the Center visits, we received feedback regarding the attribute weights, 
the utility values, and the ranking results. 

Utility Functions 

Following the assignment of the attribute weights and the utility values, 
the final step in the MADA process uses these numbers to calculate the value of 
an overall task utility of each task candidate. Once the calculations are 
completed, the candidate tasks can be ranked in the order of highest to lowest 
overall task utility. 

The overall task utility is computed by means of a utility function - a 
function of the attribute weights and the utility values. There are two forms 
of the MADA utility function: the additive form and the multiplicative form. 

Although the additive form, or weighted sum, is more intuitive in its 
design, it is restricted to being applied only when the various attributes (as 
measured by the utility values) are independent of one another, i.e., the utility 
value obtained for one attribute should not change if the utility values of 
other attributes are adjusted. This condition can be difficult to meet because 
attribute utility independence is rare in the real world. However, if the 
attribute weights are not normalized and the above condition is not met, then 
use of the additive form can result in an incorrect ranking. 

The attribute utility independence condition discussed above is the major 
complication in using the additive form. To resolve the potential problem of 
ranking errors, the multiplicative form of MADA was developed. The multiplica- 
tive form, although more complex than the additive form, is more rigorous 
because it does not require utility independence (i.e., changes in the utility 
values for one attribute can be traded off pairwise against the utility value of 
another attribute). Reference [8] provides a detailed derivation of the multi- 
plicative form of the utility function, which is as follows: 

U (x) = | {nj =1 [1 + Kk^x)] - 1) , (1) 

where U(x) , k^, n, and u-^(x) are defined above and K is a master scaling 
constant, which is inserted into the function to ensure that U(x) falls between 
0 and 1, as required by the definition of a utility value. The value of K is 
derived by setting U(x) = u(x) = 1 in the above equation and numerically solving 
the following nth order polynomial for K: 

1 + K = n" =1 (l + Kk ± ) . (2) 

Among the different real values of K, the single value satisfying -1<K<0 should 
be chosen [8]. Once K is calculated, U(x) tan be determined discretely for 
each task option through the multiplicative combination of all the attribute 
utility values for a given task. 

Task Complexity 

The scope of this study precluded the generation of detailed specifications 
for each task. A wide disparity was found in the levels of detail to which the 
tasks were described in the literature. In addition, different levels of tele- 
robotic technology advancement were required by different tasks. For these 
reasons, we introduced the notion of task-complexity levels. 

We analyzed each task from the point of view of demonstrating, in the 
laboratory, the technologies necessary to perform that task. Rather than 
selecting a single task demonstration scenario, we postulated several scenarios, 
at increasing levels of complexity, for each task: Level A was the most complex. 

Level B the second most complex, Level C the third most complex, and Level D the 
least complex. For each task, we specified scenarios for these three or four 
complexity levels. We set the levels so that there would be a high confidence 
of success if task scenarios of low complexity level (Level C or D) were to be 
demonstrated today, while those of the highest complexity level (Level A) would 
have a low confidence of success (the Level A demonstration represents the task 
as it would be performed in the real application environment) . See 
Reference [11] for specific examples of different levels of task complexity. 
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We considered only task complexity and made no assumptions about how a 
given task- complexity level should be implemented (i.e. , by teleoperation or 
automatically). Additionally, we made no attempt to correlate the complexity 
levels across different tasks; for example. Level C of one task could be more 
complex than Level B of another. 

Task breakdowns and task rankings performed in this study were done 
assuming Level-A complexity for all tasks. The task complexity levels are 
useful because they provide (1) a progression of increasingly complex demon- 
strations as a means for measuring R&D progress toward the ultimate (Level A) 
objective, and (2) a fallback implementation; if a given complexity level 
cannot be achieved within budget and schedule constraints, a lower level may 
be attainable. Each set of task levels, therefore, provides only a progressive 
set of objectives. 

Task Breakdowns 


Some of the attributes used in the task ranking depend on the technology 
required to perform a given task [12,13]. Progressive, hierarchical task break- 
downs to the task-primitive level are intended to provide the means for identify- 
ing the underlying task technologies. The low-level breakdowns can be viewed as 
generating pseudo— code subroutines for performing tasks. It is at the primitive 
level of the task breakdowns that the required technologies become apparent. 
Several studies have drawn upon task-breakdown analysis for deriving the required 


technology elements [12,13,14,15,16]. 

Task breakdowns are used only to define the required task technologies; 
they are not intended to specify the approach for implementing a task demon- 
stration, although they may serve as a good starting point. The breakdowns 
have been done from a telerobotic perspective because the demonstrations are 
intended to be performed by a telerobotic system. Care has been taken to 
ensure that the telerobotic actions are generic enough to be accomplished 
autonomously, by teleoperation, or by a mixture of both. For instance, a 
common function is to determine the location of a part. This function cou e 

performed automatically by a vision system; it could also be performed in a 
mixed mode by having the system display a processed image of the scene, whic 
helps the teleoperator determine the part's location. 


Ideally, a task breakdown would be performed for each of the tasks consid 
ered (see Table 1). However, to make the most of the limited time of t s 
study, we decided to break down only three tasks, one from each of the thr 
task categories (assembly, servicing, and inspection). We assume that tasks 
within a given category will require similar technologies so that it should be 
possible to find a Representative task. The following tasks were selected for 

breakdown : 


•Assembly: Truss Assembly 

•Servicing: Solar Maximum Mission MEB Changeout 

•Inspection: Solar— Cell Cleaning/Inspection 

A typical breakdown of one of these tasks is given in Reference [11] 


. Results 

The multiplicative-form ranking method described earlier was applied to 
rank the first 18 tasks listed in Table 1 on the basis of the initial (straw-man) 
attribute weights and utility values. These initial weights ^d values were 
later modified based on inputs from NASA Center participants, and the rank g 
was subsequently recalculated. 


Attribute Weights and Utility Values 

In our discussions with the NASA Centers it became clear that the research 
community views the relative importance of the attributes differently than the 
user community (see Table 2). For this reason we performed the task ranking tor 
two sets of attribute weights, one representing the research community, and tne 
other representing the user community. Table 4 presents the attribute we g s 
for the two cases. Feedback from the Centers also indicated that some attributes 
are not significant in ranking the tasks for one community or the other, in 
case, these attributes are not used in the ranking and do not have a weig 
(see Table 4) . 
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TABLE 4: Attribute Weights (k^ 

Attributes 

Cost 

Technology /Demo Development Schedule 
Importance to User 
Productivity/Safety Impact 
Center Resources 
Technological Contributions 
Possible Near-Term Demo Success 


User 

Community 

0.5 

0.75 

0.95 

0.95 


Research 

Community 

0.9 

0.7 

0.6 

0.7 
0. 95 
0.7 


The utility values for each task, assuming Level-A complexity, are listed 
in Table 5. 


TABLE 5: Task Utility Values u-^x) 



Attributes 1 

Tusks 

Cost 

Tech./Dctno 

Development 

Schedule 

Importance 
to User 

Productivity/ 

Safely 

Impact 

Center 

Resources 

Technological 

Contribution 

Possible Near-Term 
Demo Success 

Tel. 

Aut. 

Tel. 

Aul. 

TruSs Assembly 

0.9 

0.5 

0.5 

0.8 

1.0 

0.8 

0.8 

0.7 

0.4 

Utility Tray Deployment ... 

1.0 

0.9 

0.7 

0.7 

0.4 

0 6 

0.4 

0.7 

0.7 

S1A to 'IVuss Connection 

0.8 

0.0 

0.4 

0.8 

0.3 

0.2 

0 6 

0.4 

0.1 

PIA to SIA Connection 

1.0 

1.0 

0.9 

0.4 

0.2 

0.9 

0.3 

0.9 

08 

SDA Radiator Assembly k Deployment 

0.8 

0.0 

0.1 

0.7 

0.4 

0.2 

0.8 

0 3 

0.1 

Solar Power Converter ORU Changeout 

1.0 

1.0 

0.9 

0.4 

0.2 

1.0 

0.2 

1.0 

0 9 

1IRSO Film Canister Changeout 

1.0 

0.8 

0.4 

0.7 

0.4 

0.5 

0 6 

0.5 

0.3 

11ST Axial Instrument Changeout 

0.9 

0.6 

04 

0.8 

0-5 

0.3 

0.8 

0.5 

01 

HST RWA Changeout 

1.0 

0.8 

0.4 

0.6 

0.2 

0.5 

0 5 

0.5 

0.3 

GRO Refueling 

0.9 

0.6 

0.4 

0.7 

0.9 

06 

0.7 

0.7 

0.2 

EOS Instrunicnt/ORU Changeout 

0.9 

0.9 

0.8 

0.7 

0.6 

0.8 

0.5 

0.9 

07 

SMM MEB Replacement 

1.0 

0.4 

0.6 

0.9 

0.4 

0.7 

0 9 

0.7 

0 2 

EOS Instrument Reconfiguration 

0.8 

0.3 

0.3 

0.7 

0.6 

0.4 

0 8 

0.3 

0.1 

EOS Instrument Recalibration/ Adjustment 

1.0 

0.8 

0.5 

06 

0.6 

0.7 

0.4 

0.8 

0.7 

EVA Retriever 

0.8 

0 0 

0.6 

0.8 

0 9 

0.7 

1.0 

0.7 

0.0 

Telerobotic Docking 

0.6 

0.0 

0.3 

0.7 

0.7 

0.6 

0 7 

0.7 

0.0 

Electrical Connector Removat/Inspcction 

1.0 

0.6 

0.2 

0.7 

0.5 

0.5 

08 

0.4 

0.1 

Clcan/lnspect Surface (Solar-Cell Cleaning) 

0.9 

0.4 

0.1 

0.7 

0.6 

0.3 

08 

0.6 

0.1 


Top Ranked Task Candidates 

One of our primary objectives was to compile a suite of tasks that both 
researchers and users would find useful. We noted that five tasks appeare 
among the top eight tasks in the rankings, regardless of whether the ranking was 
performed for the user or research community, and regardless of whether the task, 
was to be mostly automated or mostly teleoperated . All of these tasks were 
basically equal and are discussed briefly as follows: 


•The EVA Retriever task has an extremely high technical contribution 
rating because it requires the combination of challenging levels of 
most technologies, including manipulation, mobility, sensing and 
perception, reasoning, and communication. This task also has a high 
rating for the attribute "Productivity and Safety." 

•The SMM MEB Replacement task also requires multiple technologies, 
and has a high "Importance to User" rating because the actions 
required to perform the task are highly generalizable to other tasks. 

•The Truss Assembly task currently would require the highest amount 
of astronaut EVA time, so it has the highest "Productivity and Safety" 
rating; in addition, it requires significant perception, reasoning, 
and manipulation technologies, yielding a high "Technical Contribution" 
score; and since some centers are already working on this task, the 
"Center Resources" rating is high. 

•The EOS Instrument/ORU Changeout task is relatively inexpensive, 
requiring only a medium-size mock-up and a single arm; it has a high 
"Importance to User" rating because there are about 50 different 
kinds of instruments on the EOS; in addition, it receives a high 
"Center Resources" score. 

•The HST Axial Instrument Changeout task is included 
because of its important technological contributions to the 
handling of large and massive objects and the use of flexible arms. 
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The subsequent technologies required to implement the tasks are shown in 
Reference [11]. Note that two utility values associated with the attributes 
’'Cost" and "Possible Near-Term Demo Success" are given for each task, one 
(marked by "Tel") assuming that the task will be controlled mostly by tele- 
operation and the other (marked by "Aut") assuming that the task will be mostly 
automated. The rationale for the selection of the utility values in Table 5 
is also given in Reference [11] . 

Decision Framework for Determining Task Objectives 


The results of the task ranking can help develop a program plan for 
both the near-term and far-term research and demonstration objectives. While 
carrying the task breakdown analysis down to the task-primitive action level, 
we became aware that the selection of tasks is highly dependent on technology 
availability. It became clear that the task demonstration selected by a 
research Center should support that Center's technology research goals. Taken 
one step further, selecting technology research goals within an application 
environment implies meeting cost, resource, and schedule constraints. There- 
fore, the decisions about what to pursue in terms of a task demonstration 
objective require an iterative process of selecting a task, comparing it with 
given technology objectives, and verifying that the schedule and resources 
limits are not exceeded. The decision framework shown in Figure 1 illustrates 
the process of using the task-ranking results, task complexity, and supporting 
task-utility data to formulate program plan objectives. The JPL $3M limit was 
used as the budget ceiling for example purposes. The 1-2 year demonstration 
cycle is the present preferred time-frame for exhibiting technologies because 
it is essential to show "progress" as a means of substantiating the associated 
yearly funding support. 



Figure 1: Decision Framework for Establishing Objectives 
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The decision framework starts with the suite of tasks composed of the 
highest ranked tasks. The key tradeoff variables are available resources, 
technology availability and schedule, cost, and importance to user. A task 
objective is selected from the suite of tasks and evaluated initially as a 
function of the cost ceiling and as to whether the technology and task 
domain can be successfully demonstrated in the near term. The next step is 
to pick the key technology elements essential to the user community and 
determine whether .the existing testbed and workforce resources. can complete 
and demonstrate the technology and the task. If the cost ceiling and 
schedule constraints are exceeded, then either a new task that is lower on 
the ranking list or a lower level complexity of the same task is examined. 
The process is repeated until task objectives that reasonably meet the 
programmatic constraints have been established. This process can be applied 
to setting both near-term and far-term task objectives. 

Conclusions 


Based on the preceding analysis, it would seem feasible to give priority 
to the development and demonstration of the five tasks listed in Table 6, 
each at the complexity level outlined in that table. 

TABLE 6: Recommended Tasks and Their Complexity Levels 


Task 


Complexity Level 


EVA Retriever 
SMM MEB Replacement 
Truss Assembly 

EOS Instrument /ORU Changeout 
HST Axial Instrument Changeout 


Level C 
Level C-B 
Level C-B 
Level A 
Level C 


■ EVA Retriever: Obstacles, moving targets, natural lighting, and 
testing the system in a 3-D environment require a significant amount 
of software and hardware development, which is probably an unrealistic 
goal for a two-year time frame. Hence, we recommend a demonstration 
task at Level C complexity. 

• SMM MEB: Portions of Levels B and C have been demonstrated for this 

task. However, manipulation of flexible materials, such as thermal 
blankets and cables, will require significant development time. For 
this reason a Level C-B demonstration is a reasonable goal in the 
near term. 

• Truss Assembly: This task has been demonstrated at Level D in the 

laboratory, both under teleoperation and automatically. A similar 
truss assembly task has been demonstrated at Level B purely tele- 
operation control. We therefore recommend a Level C-B demonstration 
in the laboratory with the emphasis on automatic operation. 

• EOS Instrument/ORU Changeout: This task has been demonstrated in 

the laboratory at a Level B complexity. Several Centers have mock- 
ups of EOS or EOS-type ORUs. Thus, there is little impact on cost 
and schedule from having to develop mock-up equipment. For these 
reasons we recommend a Level A demonstration in the near term. 

• HST Axial Instrument Changeout: A Level C complexity is recommended for 

the following reasons: Significant time and money are required to 

develop the mock-ups needed for a full-scale demonstration. In 
addition, we anticipate that a significant amount of R&D is needed to 
handle the large payloads entailed in this task in constrained areas 

by means of large flexible arms. 
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